BBS Toolkit/BBS Toolkit.iso/windows/w31thd.zip/920422B.THD

Text File | 1992-05-01 | 31KB | 706 lines

#: 103563 S9/Script/Nav Pgms [C]
    17-Apr-92  18:56:00
Sb: Oz in Win 3.1
Fm: Steve Whalen 76013,305
To: Michael Cain 74160,2326

Re: Stacks=i,j & what number will fix your problem:

I think it's unlikely you'll need to make j higher than 256, but you probably
need to move i way up if you're having interupt problems. The only formula I've
seen that made sense in calculating "i" was:

i = (#disk sectors per track) + number of other interupt devices + fudge factor

When I have interrupt overrun problems I don't usually try to outguess it.
Instead I start at

          Stacks=64,512

(the highest you can go) which usually fixes things. I then drop to 64,256 (and
things usually stay fixed).  I then work the 64 downward until things start
breaking. I stay with whatever "i" last worked. Then I'll try i,128 and if that
works, that's my "production" setting on that machine, if not, I stay with
i,256.

64,512 uses up 32k of memory, but I know if that doesn't fix things,
interrupt's aren't the problem (it's just for testing anyway).  Also,
Stacks=0,0 will make some interrupt problems go away (but sometimes that just
masks a problem).


#: 104075 S9/Script/Nav Pgms [C]
    21-Apr-92  15:49:45
Sb: Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Michael Cain 74160,2326

Here come some more comments from the peanut gallery. <g>

Since Stacks=64,512 didn't fix your problem, I think Steve (the real Steve as
in Sneed) is right that you're getting an interrupt overflow, as opposed to
data overrun or stacks getting clobbered.  The data overrun you know about. The
stacks we've pretty much eliminated with Stacks=64,512.  If you saw the
messages from Rick Harris, he's given a good description of the underlying
problem.

The only pragmatic suggestion I can make is to play with the Foreground /
Background ratios in the PIF Advanced Options for your OzCis setup. My
suggestion would be to make background a bigger number than you use for
anything else.  That way OzCis get's longer time slices.  Your foreground will
get slower (Solitare looks jerky, but you can play it).

What works best as a background ratio will vary depending on your configuration
and PC speed, so the PIF's you get from others may not be stable for you.
Living with non-premptive multitasking in Windows can be a pain.  Now if only
Os2 will get arround to living up to it's reputation, or Windows NT arrive
early (and stable)..... Steve (Whalen)


#: 104100 S9/Script/Nav Pgms [C]
    21-Apr-92  19:37:19
Sb: #104075-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: Steve Whalen 76013,305

Steve - Yeah, I have been playing with the 'priorities' and there was a
surprise for me there. I had imagined that if I said 'exclusive' execution in
the PIF that slice ratios would be somewhat moot, but not so. I had been
leaving Windows at 100,50 and Oz at 100,100. With Oz running, win apps were
still relatively responsive. I maxed Oz out at 10000,10000 and son of a gun I
thought the rest of the system had died. What the heck does exclusive mean
anyway? I'm running the online Oz at 200,200 now per your suggestion.
  I've also left stacks=16,256 (roughly your formula) and also ComxBuffer=16384
and Comboost=8 which I don't know helps or not.
  Say Steve, you seem like a knowledgeable kinda guy. That other Steve made a
suggestion to someone or other a while back to post config info for public
discussion. This seems like a good idea for all. I wonder if I could talk you
into publishing a PIF for a higher end PC (maybe 386/33, 8MB?) with commentary
for rationale of various selections? I'd do it myself but I'm scared to. Think
of the abuse you be liable for...:-)
  Won't know about NT until July I guess. I'm looking forward to it. I've got a
os/2 1.21 on my drive but I hardly ever boot it up anymore ... I have to
confess I never really liked it. Inertia I guess ...

Michael

#: 104119 S9/Script/Nav Pgms [C]
    21-Apr-92  21:12:01
Sb: #104100-Tuning Win3.1 for Oz/Comm
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326

Michael - Bravo!  Capitol suggestion!  Now, if everybody with Win3.1 problems
will gather 'round the campfire, we may make some sense of this mess...

Steve

#: 104230 S9/Script/Nav Pgms [C]
    22-Apr-92  14:57:48
Sb: #104100-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Michael Cain 74160,2326

Re: uploading a PIF with instructions:

I could put that together for Windows 3.0, but not 3.1 ( I'm waiting for the
first bug fix release to be in the pipeline before I inflict Windows 3.1 on
myself).  My current Windows setup is rock solid on a 386/33 with 8meg, but it
took a while to get it that way.

Unfortuantely PIF's aren't too transferrable between machines with different
memory, speed and usage when you're having problems.  Things as different as
having Adobe type manager loaded, what 386 memory driver you use, etc.  all can
drive you nuts getting a stable Windows.  Much of this is inherent in a
non-premptive multitasker (see Rick Harris' comments for more).  Windows
actually does quite well considering.

Re: Relative Priorities OzCis PIF

The most "portable" portion of a PIF file is the relative priority stuff. I was
suggesting you fiddle with that because it's the primary control you have over
how much of the CPU's time OzCis will get.

Instead of 200,200, I'd recommend 200,50 (background,foreground) or 200,100. At
least for Win3.0 it was the relative proportion of these two numbers to each
other in a PIF *and* the size of the number relative to other PIF's that fixed
various background problems I had.  Also, make real sure you only have 1 DOS
background task "active" at a time (mark any other DOS partitions as Foreground
Only in the PIF).

With 200,200 I'd expect it to get jerky in the foreground, WITHOUT reliably
fixing your problem, if it turns out to be fixable this way.  That's because
with 200 to the foreground, OzCis can still get ignored for a long time.

I've never left a PIF "exclusive".  I'd don't think that should be necessary,
especially with what I've heard about 3.1. There are some new "options" in 3.1
you might want to look at.  See Earl Robinson's message #104103 for a couple of
suggestions.


#: 104314 S9/Script/Nav Pgms [C]
    23-Apr-92  01:55:46
Sb: #104230-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: Steve Whalen 76013,305

Steve - Yes I know what you mean about non-portable config info. Still, it
might be useful to discuss why you have things the way you do. It's been useful
to me.
  Re priorities - Let me think about this a bit. I think you're right about
'exclusive'. There doesn't seem to be anything you can with it that you can't
do more completely with relative priorities. (BTW, I was using 'x,y' idiom as
'foreground,background'.) I've been trying to set up two DOS VM's, Oz online
and offline, especially in anticipation of Oz 2.0 enhanced message processing.
I want to give the online Oz all it needs and take whatever crumbs are left for
offline message processing. Maybe that's asking too much. The other scenario
would be online Oz and some windows apps. So I've got the windows slices (via
control panel->386enhanced) and one or two PIF slices to balance.
  I say 'let me think about this' because:

>>  With 200,200 I'd expect it to get jerky in the foreground, WITHOUT reliably
>>fixing your problem, if it turns out to be fixable this way.  That's because
>>with 200 to the foreground, OzCis can still get ignored for a long time.

  doesn't make sense to me right away. I'm so confused ... <g>

  Speaking of ControlPanel->386Enhanced, what sayest thou about MinTimeSlice
and it's impact on this situation?

Michael


#: 104572 S9/Script/Nav Pgms [C]
    24-Apr-92  14:52:59
Sb: #104314-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Michael Cain 74160,2326

Re: why I don't think 200,200 foreground / background processing slices will
fix your problem. You're right, I said it wrong. I originally wrote more, tried
to cut it down to one message, and confused it.

I was concerned about the relative priority of OzCis' BACKGROUND priority vs.
the FOREGROUND priority of whatever task you have in running at the moment in
the foreground (and other background tasks), in conjunction with the
MinTimeSlice from Control Pannel. (Boy, that really clears it up!) Anyway,I was
NOT concerned about OzCis's forground priority vs OzCis's background priority
(obviously OzCis will only be in foreground OR background at any one point in
time), even though that's what I said. Sorry.

Let me try again. The next several messages will be as much of a discussion as
I have time to prepare, and probably more than most will want to hear. I'm
focusing on this from the perspective of a DosApp (as opposed to a WinApp)
trying to run in the background (like OzCis).


               Control Pannel's MinTimeSlice:

This determines size of a time "slice" in milliseconds. This means the maximum
time in milliseconds that on process can "hog" the CPU. After this many
milliseconds, the next task that's competing for resources (hopefully) gets a
turn. Too few milliseconds = too many context switches, i.e. major overhead
(but it looks smoother). Too many milliseconds = it takes longer for a task to
get control each time, then keeps it longer, but less time is wasted on context
switches.

What's optimum depends on how fast your CPU is and how many active background
tasks you're going to have active (Formula = 1 timeslice for all WinApps + 1
timeslice for EACH Dos background task), how you have memory configured,
whether the moon is full.... I use 2 milliseconds on a 386/33 (i.e. there is
are context switches up to 500 times a second!) on a system attempting
background TeleComm.

  [OzCIS: Continued in next msg]


#: 104573 S9/Script/Nav Pgms [C]
    24-Apr-92  14:53:14
Sb: #104572-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Steve Whalen 76013,305


  [OzCIS: Continued from previous msg]



               Detect Idle Time (in the PIF).

Should be checked unless you have a real good reason why not to (like if
Windows keeps the app from running at all because it mistakenly thinks the
DosApp is idle. Windows can only guess at "idleness" with a DosApp).

 .
 .CPU Allocation when DosApp running in Background (like OzCis):
 .
 .      1 TimeSlice - Shared by all active WinApps
 .                    Each WinApp then gets part of this slice. See the
 .                    Windows manual "Set Multitasking Options" under
 .                    Control Panel and PIF for how the arithmetic works.
 .      1 TimeSlice - 1st DosApp running in Background
 .      1 TimeSlice - 2nd DosApp running in Background
 .      ...
 .      1 TimeSlice - Nth DosApp running in Background
 .

With the above in mind, here's the approach I've used to create a stable
Windows (3.0) environment:


               Enable / Disable Background processing:

WinApps: Each Windows application is expected to release any time it doesn't
need, (i.e. is expected to be well behaved). I usually enable background
processing for any Windows applications that might do something useful for me
in the background. If there's nothing I would ever want the app. to do in
background, I'll turn if off, but I tend to leave it enabled.

DosApp: I NEVER enable background processing on a Dos window I create unless I
have a real good reason to do so (like OzCis). I do it this way because all Dos
windows under Windows are ill behaved. I.E. a Dos program will tend to sit
there eating up CPU time even if it's not doing anything useful, because it's
not integrated with Windows time sharing strategy. Windows attempts to
recognize idle time and use it, but.... Also the fact that EVERY background
DosApp gets a time slice of it's own impacts TeleComm badly.


               Relative Priorities in PIF:

Background (NonTeleComm) - keep at default

  [OzCIS: Continued in next msg]


#: 104574 S9/Script/Nav Pgms [C]
    24-Apr-92  14:53:27
Sb: #104573-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Steve Whalen 76013,305


  [OzCIS: Continued from previous msg]


Background (TeleComm) - make this twice the as much as the background priority
number of any other task that will be running at the same time as when my
telecomm is running in background.

Foreground - basically leave at default, but in any case keep relatively small
numbers here to avoid jerkyness when no background telecomm is going on.


               Throw out bad applications / system utilities:

I eliminated a few applications and some system utilities that didn't appear to
properly "share" the resources.... For example, if things quit working after
installing SuperDuperUtilXYZ then I went back to whatever I used before
SuperDuper....


               Exclusive / Non-Exclusive PIF setting:

I don't use this because if I do, I have to be TOO careful of when I turn an
application loose with Exclusive, since it will upset the rest of the apple
cart. I don't want to have to remember this, my computer should. I hate
freezing a download going on in the background because I loaded an app with
Exclusive....  Same with the Control Panel "Exclusive" setting.


               Minimize number of open Dos Apps:

I minimize the number of Dos tasks that can run in background, because they
don't "share well with others". Also, I try to minimize the total number of
active tasks, because every context switch Windows has to do is an opportunity
to loose track of the Comm Port, etc.


           Now how I use all this to "balance" my system:

Basically I set the "permission" to use background as above, then make
everything the way Windows defaults it (50,100 I think). That way I know where
everything running in my Windows is, priority-wise. Then I take the one or two
TeleComm apps I want to use in the background, give them the SAME foreground
slice as everything else, and give it a background TWICE as high as anything
else. Then of course I only run 1 TeleComm app at a

  [OzCIS: Continued in next msg]


#: 104575 S9/Script/Nav Pgms [C]
    24-Apr-92  14:53:43
Sb: #104574-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Steve Whalen 76013,305


  [OzCIS: Continued from previous msg]

time.

My understanding of what Windows does with the 50,100 etc numbers is to create
a relative priority number for each running task, then ATTEMPT to arbitrate
toward those "shares". But because Windows is non-premptive, it will not "take
away" the system from another application that's hogging the CPU. It takes over
when the other goes "idle", or when the task explicitly gives up it's turn.
(And Win30 at least was not very sophisticated at figuring out when a Dos app
was "idle").

               Summary:

Basically I try to make my TeleComm app (like OzCis) "stick out" in the
priority scheme of things: it has background enabled, and it has a higher
BACKGROUND priority than any other single task's FOREGROUND priority in my
Windows setup or any other active tasks BACKGROUND priority #. By doing this,
at 2400 baud I get the same file transfer rate from OzCis under Windows as I
get under "naked" MsDos50.

Also, there is a point at which you can't have a stable system for TeleComm
under Windows. Without a pre-emptive multitasking operating system, you can't
"guarantee" the Comm program access to the port more frequently and
consistently than data can come in, especially at higher baud rates. You'd
typically get into this pickle from a combination of: too slow a CPU, too
primitive a UART, too primitive a Comm driver, too many background tasks
enabled, too little memory (if Windows has to do any swapping to disk, forget
it), etc.

This is still unfortunately an oversimplification, but if I don't send this
now, it will never get sent.....


#: 104730 S9/Script/Nav Pgms [C]
    25-Apr-92  16:29:43
Sb: #104575-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: Steve Whalen 76013,305

Steve - Very lucid discussion of a complex subject. Thanks a lot for taking
the time. Here's a summary of background execution and 'background,foreground'
priorities (basically, in general, etc.) in tabular form:

                         OnLine Oz     Others      Windows
                         ---------    --------     -------
 background execution      enabled     disabled     enabled
relative priorities       100,100      50,100       50,100

  Some comments and questions:
1) you implied at one point the ability to disable background processing for
an individual winapp. I haven't found a way to do this.
2) "(online Oz) has a higher BACKGROUND priority than any other single task's
FOREGROUND priority" - should the phrase be "higher or equal"?
3) re WinMinTimeSlice: exhaustive testing using a boot-time function to set
the min time slice in concordance with the lunar cycle showed no improvement
over one which set it randomly ... ;-)
4) worthy of note because of it's order of magnitude departure from the
windows default is your selection of 2ms vs 20ms mintimeslice. This makes
sense (if we can absorb the task switch overhead) because it does what we
can do to ensure no other app keeps control away from OnLine Oz for too
long with a side benefit of smoother overall processing.

  My thoughts on other OnLine Oz PIF settings which relate to your general
directive to minimize system overhead and swapping:

Memory Options: Lock everything to eliminate swapping to disk. You have to
have enough memory to support this.

Display Options:Monitor Ports: Monitor nothing unless you have a problem.
Should save some system overhead. Don't do online GIF display ...

Display Options:Emulate Text Mode: normally I would say check this one because
the text on it says it will make text display faster, but the other Steve's
recent report indicated just the opposite, so I don't know ...

  [>> Continued in next msg]


#: 104731 S9/Script/Nav Pgms [C]
    25-Apr-92  16:29:52
Sb: #104730-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: Michael Cain 74160,2326


  [>> Continued from previous msg]


usage notes: DOS vm's do best as full screen, next best as icons and worst
as windows. Switching between full screen and windows is risking data loss
but the risk can be minimized if you pick your spots, eg entering a forum
where CIS says 'wait a moment ...' or in a download protocol where you can
recover from data loss (at some cost). The importance of processor power,
available physical memory, com port hardware and associated driver in
relation to what you can get away with multitasking-wise cannot be over-
 emphasized.

Steve, thanks again for your analysis.

Michael


#: 105025 S9/Script/Nav Pgms [C]
    27-Apr-92  20:23:52
Sb: #104731-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Michael Cain 74160,2326

re: "...Switching between full screen and windows is risking data loss but the
risk can be minimized if you pick your spots, eg entering a forum where CIS
says 'wait a moment ...' or in a download protocol where you can recover from
data loss (at some cost)...."

Sounds like there is still some room for improvement in your Win31 vs. OzCis
background stability.  I can switch windows at will and not lose anything (I'm
too lazy to have to pick when I can open or close or switch windows). The only
time I have trouble at 2400 baud is if I have a protocol download going in the
background, and I do GIF display in the forground.  A GIF view is just about
guaranteed to suck up all the CPU available to it.  Then I get one bad block
and everything is fine.  I'd say anything less than a real CPU sucker shouldn't
have any effect on OzCis in the background.  Just switching windows shouldn't
cause even a burp.

You're right about this being a complex balancing act.  After 20 years of
trying to make mainframes, mini's, and PC's work smoothly, I'm amazed at how
things just move downhill: Mini's growing up to be mainframes (requiring
mainframe tuning approaches); and now PC's growing up to be Mini's with
multiprocessing balancing complexities.....  I bought a PC so it would be
simple to play with!


#: 105046 S9/Script/Nav Pgms [C]
    27-Apr-92  21:47:41
Sb: #105025-Tuning Win3.1 for Oz/Comm
Fm: Steve Sneed [IBMNET] 70007,3574
To: Steve Whalen 76013,305

Steve - I don't think Michael meant switching windows, I think he meant
switching just OzCIS between a full-screen (text mode) and a window - i.e. the
Alt-Enter combo.  When switching video modes like this, Windows uses the
services of the video card's BIOS... and typically, such mode switches include
having ints off for one full refresh cycle, which will cause chars to be
dropped.  Switching windows shouldn't cause any (or only minimal) adverse
effect on OzCIS.

Yeah, the LZW decompressor in a GIF decoder is typically a real processor hog.
Ditto for most other software compression tools such as PKZIP and LHA.

What Windows GIF decoder do you prefer?  I haven't found one yet I *really*
like, tho' I use PaintShop to convert GIFs to BMPs for wallpaper.

Steve


#: 105057 S9/Script/Nav Pgms [C]
    27-Apr-92  22:57:33
Sb: #105025-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: Steve Whalen 76013,305

Steve - talk about ships passing in the night :-) I read and post in the same
pass in this forum ...
  re switching: what Steve said. It was he who gently pointed this out to me in
a different thread.
  Thanks to you, in no small measure, I actually am running fairly smoothly. At
2400, I don't worry much about what I'm doing. Paintshop is ill-behaved in
places, especially where it doesn't use the meter. At 9600, I'm a little more
careful, but I'm a little more selective about when to use 9600 these days $-)
  It's funny about the emotional attachment I have to my configuration. I
hesitated a long moment in the control panel before I cut the slice down to
2ms, even with this 486/33. The effect was pleasing: smoother overall
performance and still no com trouble.
  Well, back to the mine ...

Michael

#: 104982 S9/Script/Nav Pgms [C]
    27-Apr-92  15:27:17
Sb: #104730-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Michael Cain 74160,2326

Some brief answers / comments in order of your message:

1) Disable Individual WinApp... You're right, there isn't an explicitly
documented way to do this.  You can effectively stop all WinApps from using
background by using Control Panel Windows priorites.

I think I've tried to stop WinApps by creating a PIF file for them, even though
PIF's supposedly are for DosApps. I'm not sure whether it worked (took the
PIF's settings and disabled background) or just ignored the PIF when it loaded
the EXE and found it to be a WinApp.  I never want back and specificly tested
to be sure the WinApp "stopped" in background.

2) re: Oz having higher BACKGROUND priority than any single tasks's
FOREGROUND... and whether I should have said "higher or equal"....

Actually, to really sure OzCis is "king of the heap", Oz's BACKGROUND priority
should be GREATER than the SUM of ALL other executing background DosApps and
whatever is running in foreground.   My background telecomm didn't get truly
stable until I made it higher than my standard forground priority (like 200 vs
100), so that's what I recommend.

3 & 4) MinTimeSlice.... Yeah, I was surprised that I was setting it to 1/10 of
the "default" but remember, the default created by MicroSoft had to handle 1 or
2 meg 386SX's machines running at 16 mhz.  They had to make it fairly high to
be sure the slowest machine could do a context switch.  If you think about it
20 milliseconds is only 50 context switches a second, and when 2400 baud file
transfers = 230 bytes a second arriving at the port... My 500 context switches
a second (max) sounds high until you think of the poor comm. port trying to
keep up without buffering.

Anyway, my sytem didn't get stable for Dos TeleComm until I pushed MinTimeSlice
down pretty far.  I guess it's my way of making Windows pseudo premptive
multitasking: make the context switches frequent so everybody gets

  [OzCIS: Continued in next msg]


#: 104983 S9/Script/Nav Pgms [C]
    27-Apr-92  15:27:25
Sb: #104982-Tuning Win3.1 for Oz/Comm
Fm: Steve Whalen 76013,305
To: Steve Whalen 76013,305


  [OzCIS: Continued from previous msg]

a turn.  Creates more overhead, but I always push for reliability over speed.

Locking Memory.... I lock it only for apps that have problems.  I don't mind if
a DosApp that's not going to run in background gets swapped to my pre-allocated
SwapDisk.  If I start getting too much disk swapping, I shut something down.

Monitor Ports...  I agree. Don't unless you have to.

Emulate Text... The book says it "can" increase the rate the DosApp displays
text, but instinctively I'd agree with Steve that this would add system
overhead, thus slowing system performance, especially for TeleComm in the
background.

 ...I haven't seen the continuation of your message yet. I'll respond if you
have more...


#: 104103 S9/Script/Nav Pgms [C]
    21-Apr-92  19:47:34
Sb: #104075-Tuning Win3.1 for Oz/Comm
Fm: earle robinson [ibmeur] 76004,1762
To: Steve Whalen 76013,305

I may have missed some points in this discussion, but I'd like to offer some
advice, based on my experience running win 3.1 on machines as slow as a
386sx/20, and faster ones, too.   First, one must be certain to have a ns16550a
uart, second to have the turbocom driver, the only one that supports dos
communications applications.  Finally, be sure and set the relevant parameters,
which include the ComBoostTime and ComnBuffer on slower systems. Try at least 2
for the former and 256 or 512 for the latter.  The defaults, I think, are 1 and
128 respectively.  In fact on faster systems I've not even needed to change the
defaults.   -er

#: 104151 S9/Script/Nav Pgms [C]
    21-Apr-92  23:25:48
Sb: #104103-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: earle robinson [ibmeur] 76004,1762

addendum to er's note: (from WINADV)

This from the April 28 PCMag p. 143:

 "At this writing, Microsoft was still trying to improve the communication
driver's support for the 16550 UART.  Windows communication programs can access
the UART, but the driver was not yet able to virtualize the UART in DOS
sessions.  Because Windows 3.1 needs to virtualize the communications driver,
DOS programs running under Windows could not use the 16550's FIFO buffer.
Microsoft expects that it will distribute enhanced versions of the COMM.DRV
file through its CompuServe forums and technical support within a few months."

 The TurboCom driver overcomes this current limitation.

mwc

#: 104297 S9/Script/Nav Pgms [C]
    22-Apr-92  23:41:58
Sb: #104103-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: earle robinson [ibmeur] 76004,1762

er - In addition to it's nifty buffer, does the 16550 allow the potential for
reduced interrupts by allowing several characters to be pulled from the buffer
under one interrupt as opposed to one interrupt per character otherwise?

Michael


#: 104303 S9/Script/Nav Pgms [C]
    23-Apr-92  00:18:54
Sb: #104297-Tuning Win3.1 for Oz/Comm
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326

Michael - Reduced interrupts is the whole point of the FIFO buffer in the
16550A UARTs.  Software that recognizes and properly utilizes the 16550A can
set a "trigger level" for the buffer, and no receive interrupt is generated
until the buffer fills to that level or a specific amount of time passes with
no received char but with chars in the buffer, at which point the program goes
and gets all chars in the buffer in one shot.  This reduction of ints is
important under multitasking software such as Windows or DesqView.

Unfortunately, the current COMM.DRV supplied with Windows neither virtualizes
the UART for DOS apps nor allows use of the FIFO buffer in the 16550A chip.  At
least one aftermarket replacement driver allows such support, but asking a user
to go out and buy a $50 driver so he can run his DOS comm apps under Windows is
like buying a car and having to go buy tires someplace else; such products are
much more viable when sold as part of a Windows-specific comm package, and
should not be required for DOS apps anyway.  (Windows fails to protect apps
from each other when accessing memory, but breaks it's back protecting comm
apps from each other.  Sigh...)

Just as bad, more and more machines today are comming with the serial ports on
the motherboard.  Almost always these motherboards use ASICs (application
specific ICs) that provide two serial ports and a parallel port in one chip.
Neat, but the ASICs are all 16450 clones, not 16550A workalikes, so you don't
get the FIFO advantage - on fast machines destined for multitasker use.  Brain
damaged design, to save a couple of bucks per board and a milliwatt or two of
power consumption.  Plus most of the ASICs have some compatibility problems.

Steve (down from soapbox...)


#: 104316 S9/Script/Nav Pgms [C]
    23-Apr-92  02:36:15
Sb: #104303-Tuning Win3.1 for Oz/Comm
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574

Geez Steve, too bad we can't get you pumped up about this <g>

  Well, I myself am a poor ASIC sufferer, although I have it on a card with two
serial, parallel and game port. MSD calls it an 8250. I was kinda hoping to see
the new MS comm.drv before too long and I've been looking for a 16550 card to
plug in.
  Amazing I don't have more com trouble than I do, huh?
  BTW, I saw a mention from MS tech support in winadv to the effect that a dos
vm can get at the 16550 fifo by using ComxBuffer=0 in sys.ini.

Michael

#: 104511 S9/Script/Nav Pgms [C]
    24-Apr-92  07:20:32
Sb: #104316-Tuning Win3.1 for Oz/Comm
Fm: earle robinson [ibmeur] 76004,1762
To: Michael Cain 74160,2326

Steve has already answered, so all I can do is to agree about the asic
business.  I have a couple of expensive toshiba machines with those damned
asic's, and had to buy a serial port with a ns16550 uart in order to get the
benefits.

As for the comxbuffer=0 business, I recall some mention of this during the
final weeks of the win 3.1 beta testing.  But, I also remember the fellow
responsible for the windows comm driver saying that dos comm support would be
provided later if there was demand.  Since microsoft, in its own enlightened
self interest is trying to wean people away from dos applications to windows
ones, I'd not hold my breath too long for that.
 -er